add non-es6-compat to importSync #1076
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
importSync should do the same thing that regular static import does when you use it against as non-es-module.
|
Last failures here are some tests that need to be updated to expect this newer format. But I'm thinking I'll take a stab at sharing this new compat code, rather than inlining it everywhere. It's tiny, but we use it a lot. |
and adopt babel-import-util to clean things up better
chancancode
added a commit
to tildeio/embroider
that referenced
this pull request
Jul 13, 2023
`importSync()` is intended to work like `import()` (buy sync),
which, in turns, is expected to work like a namespace import –
`import * as NS from "foo";`. In general, we would expect that to
be interchangable with `const NS = importSync("foo");`.
Prior to this commit, this is not true for commonjs packages:
```js
import * as QUnit1 from "qunit";
// => { QUnit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit");
// => { default: { QUnit, assert, begin, config, ... } }
QUnit2.assert // => undefined
```
Of course, using ES imports on commonjs packages is, in itself, an
ill-defined concept, but nevertheless, it is a very common interop
requirement.
The previous behavior is introduced in embroider-build#1076. The intent appears to
be fixing a different interop issue, where we would expect these to
work the same way:
```js
import QUnit1 from "qunit";
// => { Qunit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit").default;
// => { QUnit, assert, begin, config, ... }
QUnit2.assert // => function
```
The fix in embroider-build#1076, however, broke the exepctation that `import()`
should behave like a namespace improt statement for CJS modules.
This commit attempts to satisfy both of these requirements, with
one caveat: `importSync("foo").default` is present on the shimed
CJS modules, but in `import * as FOO from "foo";`, `FOO.default`
is undefined.
Arguably, this is a bug in webpack's implementation – if you are
able to write an import statement that references the default
export, you should be able to do the same in the namespace import
as per the spec.
So, the implementation here is different but more correct.
chancancode
added a commit
to chancancode/embroider
that referenced
this pull request
Jul 13, 2023
`importSync()` is intended to work like `import()` (buy sync),
which, in turns, is expected to work like a namespace import –
`import * as NS from "foo";`. In general, we would expect that to
be interchangable with `const NS = importSync("foo");`.
Prior to this commit, this is not true for commonjs packages:
```js
import * as QUnit1 from "qunit";
// => { QUnit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit");
// => { default: { QUnit, assert, begin, config, ... } }
QUnit2.assert // => undefined
```
Of course, using ES imports on commonjs packages is, in itself, an
ill-defined concept, but nevertheless, it is a very common interop
requirement.
The previous behavior is introduced in embroider-build#1076. The intent appears to
be fixing a different interop issue, where we would expect these to
work the same way:
```js
import QUnit1 from "qunit";
// => { Qunit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit").default;
// => { QUnit, assert, begin, config, ... }
QUnit2.assert // => function
```
The fix in embroider-build#1076, however, broke the exepctation that `import()`
should behave like a namespace improt statement for CJS modules.
This commit attempts to satisfy both of these requirements, with
one caveat: `importSync("foo").default` is present on the shimed
CJS modules, but in `import * as FOO from "foo";`, `FOO.default`
is undefined.
Arguably, this is a bug in webpack's implementation – if you are
able to write an import statement that references the default
export, you should be able to do the same in the namespace import
as per the spec.
So, the implementation here is different but more correct.
chancancode
added a commit
to chancancode/embroider
that referenced
this pull request
Jul 13, 2023
`importSync()` is intended to work like `import()` (buy sync),
which, in turns, is expected to work like a namespace import –
`import * as NS from "foo";`. In general, we would expect that to
be interchangable with `const NS = importSync("foo");`.
Prior to this commit, this is not true for commonjs packages:
```js
import * as QUnit1 from "qunit";
// => { QUnit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit");
// => { default: { QUnit, assert, begin, config, ... } }
QUnit2.assert // => undefined
```
Of course, using ES imports on commonjs packages is, in itself, an
ill-defined concept, but nevertheless, it is a very common interop
requirement.
The previous behavior is introduced in embroider-build#1076. The intent appears to
be fixing a different interop issue, where we would expect these to
work the same way:
```js
import QUnit1 from "qunit";
// => { Qunit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit").default;
// => { QUnit, assert, begin, config, ... }
QUnit2.assert // => function
```
The fix in embroider-build#1076, however, broke the exepctation that `import()`
should behave like a namespace improt statement for CJS modules.
This commit attempts to satisfy both of these requirements, with
one caveat: `importSync("foo").default` is present on the shimed
CJS modules, but in `import * as FOO from "foo";`, `FOO.default`
is undefined.
Arguably, this is a bug in webpack's implementation – if you are
able to write an import statement that references the default
export, you should be able to do the same in the namespace import
as per the spec.
So, the implementation here is different but more correct.
chancancode
added a commit
to chancancode/embroider
that referenced
this pull request
Jul 13, 2023
`importSync()` is intended to work like `import()` (buy sync),
which, in turns, is expected to work like a namespace import –
`import * as NS from "foo";`. In general, we would expect that to
be interchangable with `const NS = importSync("foo");`.
Prior to this commit, this is not true for commonjs packages:
```js
import * as QUnit1 from "qunit";
// => { QUnit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit");
// => { default: { QUnit, assert, begin, config, ... } }
QUnit2.assert // => undefined
```
Of course, using ES imports on commonjs packages is, in itself, an
ill-defined concept, but nevertheless, it is a very common interop
requirement.
The previous behavior is introduced in embroider-build#1076. The intent appears to
be fixing a different interop issue, where we would expect these to
work the same way:
```js
import QUnit1 from "qunit";
// => { Qunit, assert, begin, config, ... }
QUnit1.assert // => function
const QUnit2 = importSync("qunit").default;
// => { QUnit, assert, begin, config, ... }
QUnit2.assert // => function
```
The fix in embroider-build#1076, however, broke the exepctation that `import()`
should behave like a namespace improt statement for CJS modules.
This commit attempts to satisfy both of these requirements, with
one caveat: `importSync("foo").default` is present on the shimed
CJS modules, but in `import * as FOO from "foo";`, `FOO.default`
is undefined.
Arguably, this is a bug in webpack's implementation – if you are
able to write an import statement that references the default
export, you should be able to do the same in the namespace import
as per the spec.
So, the implementation here is different but more correct.
Fixes embroider-build#1530
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
importSync should do the same thing that regular static import does when you use it against as non-es-module.